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INTRODUCTION 

A space mission operations system is a complex 
network of human organizations, information and deep- 
space network systems and spacecraft hardware. As in 
other organizations, one of the problems in mission 
operations is managing the relationship of the mission 
information systems related to how people actually work 
(practices). Brahms, a multi-agent modeling and 
simulation tool, was used to model and simulate NASA’s 
Mars Exploration Rover (MER) mission work practice. 
The objective was to investigate the value of work 
practice modeling for mission operations design. 

From spring 2002 until winter 2003. a Brahms 
modeler participated in mission systems design sessions 
and operations testing for the MER mission held at Jet 
Propulsion Laboratory (JPL). He observed how designers 
interacted with the Brahms tool. This paper discusses 
mission system designers’ reactions to the simulation 
output during model validation and the presentation of 
generated work procedures. This project spurred JPL’s 
interest in the Brahms model, but it was never included as 
part of the formal mission design process. We discuss 
why this occurred. Subsequently, we used the MER model 
to develop a future mission operations concept. Team 
members were reluctant to use the MER model, even 
though it appeared to be highly relevant to their effort. We 
describe some of the tool issues we encountered. 

BRAHMS 

Brahms was conceived as a business process 
modeling and simulation tool that incorporates the social 
systems of work, thus illuminating how formal process 
flow descriptions relate to people’s actual located 
activities in the work place [Clancey. Sachs, Sierhuis and 
van Hoof 199S] [Sierhuis and Clancey 2002]. Research 
for developing Brahms started in the earlv nineties as a 


Wiiiiam J. Ciancev 

NASA Ames Research Center and Institute for Human 
and Machine Cognition 
wiiliam.i.ciancev@nasa.gov 

reaction to experiences with work process modeling and 
simulation in the Tl-order process redesign project at the 
NYNEX Corporation [Sachs 1995]. The workflow 
modeling-paradigm environment (Sparks™ from Coopers 
& Lybrand) was unable to represent social systems that 
played a role in how work actually got done in the 
NYNEX organizations so Brahms was developed to not 
only incorporate all benefits of work process modeling 
and simulation, but to distinctively relate people, 
locations, systems, artifacts, communications and 
information content. 

Brahms comprises of an agent-based modeling 
language and simulation environment based on an agent 
modeling language [van Hoof and Sierhuis 2000]. People, 
robots and systems are modeled as agents and objects with 
behaviors as conditional activities. Agent behaviors are 
dynamic, responsive to changes in the environment. 
Conditional activities within ‘workframes’ allow' 
experimentation with different work scenarios by 
modifying the agents’ environment or ‘beliefs’. 

The state of the w'orld in Brahms is modeled as 
‘facts’. Agents become aware of these facts through 
‘detectables’ w'hich results in agent belief about the 
environment. Changed beliefs then activate workframes. 
The conditionality of activities is defined by 
‘preconditions’ w hich are matched against agent beliefs. 
Therefore, behaviors are data-driven. The activities 
performed by an agent can change its beliefs as well as 
facts in the world. Multiple activities within an agent can 
be active concurrently but are either in an interrupted or 
impasse state. An agent performs only one activity at a 
time. The simulation work selector determines, based on 
the priorities, w'hich activity an agent performs at every 
state change. 

The Brahms Virtual Machine (VM) (Figure 1), 
schedules and manages state changes and the initiation, 
interruption, impasse, resumption and termination of 
activities through a discrete event engine that coordinates 
simulated time between all agents with a centralized 
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scheduler. The Brahms VM captures all agent behaviors 
in a file for later analysis. 


Brahms integrated Development Environment (IDE) 



Figure 1. Brahms Environment 
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If so desired, a designer could manually update the 
generated simulation model outside of the design views by 
manipulating code; changes are automatically reflected in 
the design views. 

The Brahms Agent Viewer (Figure 3), another part of 
the Brahms IDE, parses a file generated by the Brahms 
VM into a database and provides the simulation 
visualization of the agent behaviors, collaborations and 
state changes. The visualization shows a chronological 
history of what activities are performed by people or 
robots, who works with whom, where and when. The 
visualization also shows tools or systems in use by 
particular people or robots and when information is 


The Brahms Integrated Development Environment (IDE) 
includes the Brahms Composer (Figure 2). The Brahms 
Composer offers various connected design views that are 
based on the World Modeling Framework [Selvin 1999], 
including: organization/people, artifact/system, 
data/information, geography/location, communications, 
activity/task and timing/flow. These design views present 
modeled concepts, such as agent groups, objects and 
geography, hierarchically for convenient access. 

The Composer's multiple views also allow a modeler 
to graphically create and edit concepts; these are 
automatically converted into a simulation model for input 
to the Brahms VM. 
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Figure 3. Brahms Agent Viewer 
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The Mars Exploration Rover (MER) mission to the 
surface of Mars is a dual-robot mission w ith unprecedented 
operational capabilities and provided new operational 
challenges. With a complement of remote sensing and in-situ 
science instruments, and the ability to traverse a distance in 
one day roughly equivalent to the distant traversed by 
Pathfinder's Sojourner Rover over its entire mission 
lifetime, the scientists seek to determine the history' of 
climate and water at a site on Mars where conditions may 
once have been favorable to life. 

The first rover. Spirit, was launched during the summer 
of 2003 followed a month later by its twin. Opportunity. 

Both rovers landed safely on Mars in the early' part of 2004. 
The Jet Propulsion Laboratory (JPL) in Pasadena. CA. 
started twenty-four hours, round-the-clock mission 
operations when the rovers landed. Scientists and engineers 
worked together at JPL to plan and operate the science 
instruments on the rovers. After the first three months of 
suiface operations, JPL scaled back its operations to a 
roughly eight hours a day schedule. 


IiRAHMS MODEL OF MER 

The task of the MER mission designers was to integrate 
legacy systems with newly developed systems plus to set up 
work processes for scientists and engineers in three shifts 
during a twenty-four hour period. Their challenge was to 
create a seamless workflow that would get the most 
productivity out of the rover on Mars. 

In late 2002, the first author, Chin, participated in JPL’s 
mission operations design meetings and researched the 
mission operations design documentation. He interviewed 
key MER team members, asking them to describe their 
future MER mission operations job activities, information 
needs, interfaces and tools. From this data, we created an 
initial MER mission operations model and simulation in 
Brahms. As a heuristic for completeness, we chose a 
scenario that covered a complete sol (Martian day) of 
mission operations. 

Contents of Model 

The main activities within a sol were to receive data 
from the rover, convert data for analysis, discussions and 
archival by the Earth-based team, make decisions on what 
the rover should do next, and send command data to the 
rover (Figure 4). In the simulation scenario, scientists and 


engineers work together to create m coniputci systems 
artifacts, such as the Uplink and Downlink Reports and 
Rover Activity Plans which are the focus of their discussions 

everyday. 

Following JPL’s design of the MER mission operations 
organization, people were modeled as groups of Brahms 
agents. For example, we included Brahms agents 
representing discipline-specific scientists within the Science 
Operation Working Group (SOWG). The Mars rovers were 
also modeled as agents because they had activities including 
movements and communications that changed their 
environment 



Physical objects, such as science instruments, the 
instrument deployment device on the rover, communication 
devices and software systems were modeled as Brahms 
objects. Similarly, artifacts including data, reports and plans 
were also modeled as Brahms objects. 

The mission operations timeline (Figure 5) for a single 
sol stated the time and duration of each work process at a 
high-level. For example, during the SOWG meeting, 
scientists and engineers come together to decide what 
science experiments the rover should perform. We modeled 
a ‘SOWG Meeting’ as a conditional activity that states that 
when the clock in the agent’s office is 7:00pm. the activity' 
becomes active. Depending on priority of other activities, 
the agent will interrupt what it is doing to engage in the 
‘SOWG Meeting’ activity. 



Figure 5. MER Mission Operations Timeline 


VALIDATION OF MER MODEL 

We approached the mission operations designers for 
validation and verification. 


Validation Using Brahms Composer 

At the time, the Brahms Composer was still being 
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ci so we did not hnvs design views to present the 


model to the designers. To show the designers what was 
contained in the model, we used simple class-object 
diagrams (Figure 6). 



Figure 6 . MER Mission Operations Agent Group Hierarchy 

Validation Using Brahms Agent Viewer 

We could not install the Brahms Agent Viewer on JPL’s 
predominantly Apple computers because of operating 
system incompatibility. However, we collaborated with 
another group developing a large computer-based white 
board, called the MERBoard (Figure 7) [Trimble, Wales and 


Gossweiler 2002J, for the MER mission and we w'ere able to 
display the model’s simulation visualization on it. 

Observation of User Validation 

Using the MERBoard as a platform, we could get the 
mission designers to interact with the model. We trained 
them on how to use the Brahms Agent Viewer and 
discovered that they had very little trouble navigating the 
simulation visualization. We believe that because the 
designer's 'mental model' [Norman and Draper 1986] of the 
MER mission operations timeline (Figure 5) was very close 
to Brahms Agent Viewer's presentation ot the simulation 
(Figure 3), the designers were able to quickly start analyzing 
the simulation output. 



Figure 7. Brahms Agent Viewer on MERBoard 


We presented to the mission designers a problematic 
exchange of information between agents on the MER 
mission operations timeline that we had discovered in the 
simulation output. We listened to the designers discussions 





about this issti? and observed how the v interacted with the 
Brahms Agent Viewer. 

From their discussions, we understood that the 
designers were looking in the work system design for 
someone who would be available to receive the information 
during the problematic period on the timeline. This person 
would need to pass the information along at a later time to 
someone else who required the information but was 
unavailable during the earlier time period. 

We observed the designers looking at multiple agents’ 
activities on the timeline displayed by the Brahms Agent 
v iqwqy The designers were constantly scrollin' 7 tip and 
down’ within the Brahms Agent Viewer because it could 
only display three agents or objects on the screen (Figure 3). 
For the same reason, we noticed the designers were ‘closing’ 
and ‘opening’ different agent’s timeline for display. 

Other Validation Output 

The mission designers requested for us to generate a 
listing of the activities that each agent performs within a 
timeline period. They wanted to use the listings to develop 
operational procedures for mission operations personnel. 

We believe that because the designers could not install 
the Brahms Agent Viewer on their personal computers, they 
asked for paper copies of the output and mentioned that they 
would like to annotate on paper for their own use and to 
provide us with additional feedback. We generated a very- 
large paper poster by capturing screen-shots of the Brahms 
Agent Viewer; we posted it on a large wall in their office 
area. W T e saw no annotations on the poster when we returned 
to inspect it when the mission started. 

We did get feedback from the mission designers about 
desirable simulation visualizations. The designers wanted to 
be able to easily see where the agents were geographically 
located for a given period on the timeline, especially during 
meetings. They also wanted to easily see what information is 
put on a rover activity plan as the plan is progressively 
modified during daily operations. In addition, they suggested 
it would be helpful to show communication networks that 
get created and grow as information gets communicated 
between agents as the day progresses. 

USE OF MER MODEL IN MISSION 

After developing the initial MER work practices model, 
the first author. Chin continued to participate in mission 
operations design sessions and observed field tests that JPL 
conducted to validate the mission operations design. With 
experience gained from the field tests, the designers 
modified their designs. W T e found that due to the high- 
fidelity of our Brahms model, we were unable to keep up 
with the fast-paced changes that were occurring to the 
mission operations designs. Even when the Brahms 
Composer became available, we were unable to incorporate 
the changes m the mission operations designs to provide 
timely' and useful feedback to the mission designers. 


JPL designers felt that vve did iiot provide Luuelv 
modifications and analysis from the model and did not fulfill 
their requests for additional simulation output. 

Consequently, Brahms was never included as part of JPL’s 
formal design tool for the MER mission. 

NEW USE OF MER .MODEL 

In summer 2004, a group at NASA Ames Research 
Center was formed to collaborate with JPL to research and 
develop new architectures and technologies for operating 
future autonomous robots on planetary' missions. Most of the 
people in the sroiip hnd been involved with the ^TER 
mission as developers of applications used by the mission 
operations team. We were asked to participate in the group 
to share the broader workflow and mission operations 
knowledge we had gained from the MER mission. 

We were keen on working with the group to modify the 
MER mission model, based on the new architectures and 
technologies discussed for future robotic missions. We 
presented the MER mission operations model and simulation 
developed using the Brahms Composer and Brahms Agent 
Viewer. After our presentation, we were surprised that the 
group decided to study and evaluate other modeling tools 
and environments. 

MER MODEL IN UML 

We were told by the group that they preferred to utilize 
a modeling technique with which they were all familiar. The 
majority of the people in the group were familiar with the 
Unified Modeling Language (UML) (Booch, Jacobson and 
Rumbaugh 1999]. They wanted a modeling tool that used 
UML and could produce printouts and be exportable into 
other graphical modeling or ontology tools. 

The group learned about a standard, called XML 
Metadata Interface (XMI) [Object Management Group, Inc. 
2002], currently being used by several UML tool vendors 
for importing and exporting models. Consequently, the 
group chose a tool that was able to export and import XMI 
files. 

We investigated whether Brahms models could be 
exported based on the XMI specifications. We were able to 
develop an interface to our current agent modeling language 
and output XMI compliant files. We were then able to 
import the model into the chosen UML tool and display the 
MER mission operations model within the tool (Figure 8). 

As a benefit of importing to a UML tool, we could now print 
out our models, instead of manually drawing diagrams 
(Figure 6) using another tool. 

Currently, the group is extracting information from the 
UML models that we generated from the MER model to 
prepare for a pilot demonstration of their technology 
architecture at the end of 2005. 



Figure 8. MER Science Team modeled in UML 


CONCLUSION 

We have learned that researching and developing a tool, 
like Brahms, for modeling and simulating complex human- 
robot work processes is both technically and 
organizationally complex. From our experience of modeling 
the MER mission operations work processes and then using 
the model for another project where the model is relevant, 
we have realized that we still need to improve our Brahms 
environment for ease of use and compatibility with other 
tools. We continue to research and develop user interfaces 
for modeling and visualizations for simulations. 

When we have users who are not trained in modeling, 
yet are able to interact with the models and understand 
simulation results in our Brahms environment, then we will 
say that we have a ‘user friendly’ and 'easy to use’ tool. 
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